subscription: return parent node to oper_state callback#45
subscription: return parent node to oper_state callback#45avazquezrd wants to merge 1 commit intosysrepo:masterfrom
Conversation
rjarry
left a comment
There was a problem hiding this comment.
Hi Adrián,
thanks for your patch. I am not comfortable with breaking the API. Would it be possible to change the xpath argument to convey some information about the actual list item that is being refered?
In the linked issue sysrepo/sysrepo#1786 it mentions that it is possible to call lyd_path(*parent) to get the actual requested node.
What do you think?
fd65512 to
f6de384
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #45 +/- ##
==========================================
- Coverage 66.93% 66.54% -0.40%
==========================================
Files 8 8
Lines 1113 1064 -49
==========================================
- Hits 745 708 -37
+ Misses 368 356 -12 ☔ View full report in Codecov by Sentry. |
|
Hi sorry for the very long delay. I had a second look and I am still not comfortable with breaking this API. I had an idea: we could add a What do you think? |
Hi! I had already forgotten about this issue 😅. I think that it would be enough to distinguish between different leafs in a list, yes. Another thing I mentioned in my initial comment is that the |
587f88c to
0df4d2e
Compare
|
Hi! I have added requested changes, now the |
0df4d2e to
19fa87b
Compare
The only way to differentiate two calls when there is a subscription on an internal element of a list is by using the parent node. Moreover, in these cases, it is on this parent node that the data structure to be returned must be built. Signed-off-by: Adrián Vázquez <32303781+avazquezrd@users.noreply.github.com>
19fa87b to
362f5b2
Compare
|
Hi @rjarry, any new comments on this? I'm not sure why the GitHub workflows are failing, but it seems more like a setup thing. |
We have a Sysrepo plugin that is subscribed as operational data provider to
/ietf-hardware:hardware/component/softwareleaf, which generates a call for eachcomponentwhen/ietf-hardware:hardwarenode is requested (as expected). The problem is that with the parameters currently available inOperDataCallbackType(xpath,private_data), it is not possible to distinguish between components. Similar problem withinterfaces-statemodule is described here.The solution proposed in that issue consists of using the parent node that is returned, since in this case the state must also be built on this parent node. This parent node has the path with the key we need, so we can distinguish between components.
This pull request adds the parent node as parameter exposed in operational state request callback.